home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 1024 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.5 KB
  1. From: "Wil Evers" <wil@ittpub.nl>
  2. Message-ID: <009A0A5CE1159CC0.49802F14@ittpub.nl>
  3. X-Original-Date: Wed, 10 Apr 96 11:54:04 WET
  4. Path: in2.uu.net!bounce-back
  5. Date: 10 Apr 96 11:22:47 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Organization: -
  8. Newsgroups: comp.std.c++
  9. Subject: Re: sample auto_ptr template
  10. X-Vms-Mail-To: IN%"std-c++@ncar.ucar.edu"
  11. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  12.     iQBFAgUBMWuaMOEDnX0m9pzZAQF5twGAk1ogp8b8bhyt8mF/bSLTW3ZkAbtfIn3n
  13.     4xdgwn00Pxxx/LIVYIfTeE3nMk3Kssb3
  14.     =4vkF
  15.  
  16. In article <gregorDpFBCt.A5@netcom.com> gregor@netcom.com (Greg
  17. Colvin) writes:
  18.  
  19. > Please remember that auto_ptr is designed to make sure that pointers
  20. > are deleted when exceptions are thrown, not to be sure that already
  21. > deleted pointers are not misused.  The semantics of auto_ptr are
  22. > intentionally "as close as possible" to ordinary pointers: if you
  23. > use a pointer that is already deleted the behaviour is undefined,
  24. > and the same for auto_ptr; if you use a pointer that is owned by
  25. > another object (i.e. will be deleted by that objects destructor) the
  26. > behaviour is well defined as long as the pointer remains valid, and
  27. > the same for auto_ptr; you cannot tell at runtime whether a pointer
  28. > is valid, and the same for auto_ptr.
  29.  
  30. My original question was "Did the committee explicitly decide to allow
  31. dereferencing of non-owning auto_ptrs?  If so, what is the rationale
  32. behind this?"  It seems to me Greg's answer is "Yes, because that's
  33. what ordinary pointers do."  I cannot understand this.  Why allow a
  34. dangerous operation just because ordinary pointers do not prohibit it?
  35.  
  36. Please note:
  37.  
  38. 1. The previous (April '95 DWP) incarnation of auto_ptr did not forbid
  39. to have a second, non-owning, pointer to the owned object.  However,
  40. in order to get one, we had to explicitly call the get() member
  41. function, which returns an ordinary pointer.  In my opinion, requiring
  42. the user to go through all this trouble was a reasonable safeguard
  43. against accessing released memory and unintended aliasing.  In the new
  44. incarnation, there are no such guarantees: an auto_ptr silently
  45. changes into a zombie pointer as a side effect of a copy operation.
  46.  
  47. 2.  We all have to pay the price for the committee's decision.  The
  48. new implementation is about twice as complicated - up to the point
  49. where almost no existing compiler can handle it - and half as
  50. efficient.  Furthermore, dropping a guarantee always breaks existing
  51. code.
  52.  
  53. What I definitely do not understand is why the new auto_ptr template
  54. doesn't even allow us to query if it is actually owning the object
  55. pointed to. 
  56.  
  57. > What you can do is design your code so that you know who owns each
  58. > object when.  The auto_ptr template can help you implement such
  59. > designs safely.  If you cannot design your code to work with
  60. > auto_ptr you probably need garbage collection of some form.
  61.  
  62. auto_ptr may have been designed to provide only limited functionality,
  63. but since it is the only heap object management facility in the
  64. standard, it will be used in many different contexts.  Therefore, I
  65. think it is quite resonable to ask how easy it is to abuse it.  What I
  66. dislike about the new auto_ptr incarnation is that it is even easier
  67. to abuse than the old one.
  68.  
  69. - Wil
  70. ---
  71. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  72. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  73. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  74. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  75. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  76.